Restore from nuget.org alone - #571
Conversation
NuGet.config named a local feed by absolute path. That path existed on one machine, so every restore anywhere else failed with NU1301 before reaching nuget.org - an unreachable source is an error, not a source to skip. The build job on main has been red since.
|
Found while looking at why #570 (an actions/cache bump that touches nothing but a workflow file) had a red build. The failure is not that pull request's — To keep using a local feed, add it per-machine instead: |
An XML comment cannot contain '--', so the explanatory comment made NuGet.config unparseable and traded one restore failure for another.
Cratis.Chronicle.XUnit.Integration 16.16.0 requires Testcontainers 4.13.0 and the repository pinned 4.12.0, which restore rejects as a downgrade rather than resolving upward. Microsoft.NET.Test.SDK was also declared twice, differing only in the case of 'Sdk' - package ids are case insensitive, so the two entries were one package pinned to two versions.
The console quickstart is written against Terminal.Gui 1.x, where Dialog, Window, Label and TextField sit directly in the Terminal.Gui namespace. It was pinned to 2.4.11, which moved them, so the sample has not compiled since it was added.
|
Four separate faults, found by pulling on the first. The Terminal.Gui pin is the one worth a second opinion: pinning back to 1.19.0 matches the sample as written, but migrating the sample to 2.x is the other direction and a larger change. I took the pin because it restores a green build without rewriting sample code. |
Pinning back to 1.x is the wrong direction: the designer-generated files use ViewArrangement, Alignment and ListWrapper, which are 2.x. The console sample needs the namespaces its 2.x version actually uses, not an older library, and that is a change to the sample rather than to a version.
|
Restore now works.
That makes it a change to the sample, not to a version — either the designer files get the namespaces 2.4.11 actually uses, or the sample is regenerated against it. I left the pin at 2.4.11 and stopped there rather than guess at the library's current namespace layout. Worth knowing this predates the pull request: the sample was added with a 2.x pin against code that does not compile on it, so |
The Cratis package updater moved the Chronicle pins to 16.16.1 on main while this branch was open. Taking main's versions; the Testcontainers floor and the duplicate test SDK entry are unaffected.
The console quickstart was written when Dialog, Window, Label, TextField and ListView sat directly under Terminal.Gui. 2.x splits them across Terminal.Gui.Views, .ViewBase, .Input and .App, so the sample has not compiled against its own pinned version since it was added. Namespaces taken from lib/net10.0/Terminal.Gui.xml in the 2.4.11 package rather than inferred: Views for the widgets and ListViewItemEventArgs, ViewBase for ViewArrangement and Alignment, Input for CommandEventArgs, App for Application.
|
Took the Terminal.Gui fix after all, once I could stop guessing at it. I pulled That is the direction the earlier comment left open, and the pin stays at 2.4.11 — the sample was always 2.x code, only pointed at 1.x namespaces. |
|
The namespace layer is done — every
Each of those is a decision about what the sample should do, not a rename, and picking wrong changes runtime behaviour without failing the build. Worth someone deciding rather than me guessing. Everything before that point is verified rather than assumed: the three restore fixes by a clean restore, the namespaces by reading them out of the package. |
1 participant
Fixed
NuGet.confignamed a local feed by an absolute path that exists on one machine. An unreachable source is an error rather than a source to skip, so the restore never reached nuget.orgTestcontainerswas pinned below the 4.13.0 thatCratis.Chronicle.XUnit.IntegrationrequiresMicrosoft.NET.Test.Sdkwas declared twice, differing only in the case ofSdk, so one package carried two pinned versionsDialog,Window,Label,TextFieldandListViewdirectly underTerminal.Gui, where 2.x no longer keeps them